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Abstract 


The document describes a proxy-based mechanism allowing the use of 


Duplicate Address Detection 


architectures. 


(DAD) 
multipoint architecture with a "split-horizon" 
primarily deployed for Digital Subscriber Line 
Based on the DAD signaling, 


by IPv6 nodes in a point-to- 
forwarding scheme, 
(DSL) and Fiber access 
the first-hop router 


stores in a Binding Table all known IPv6 addresses used on a point- 


to-multipoint domain (e.g., 


VLAN). 
address already used by another node, 


When a node performs DAD for an 
the first-hop router defends 


the address rather than the device using the address. 
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1. Introduction 


This document specifies a function called Duplicate Address Detection 
(DAD) proxy allowing the use of DAD by the nodes on the same point- 
to-multipoint domain with a "split-horizon" forwarding scheme, 
primarily deployed for Digital Subscriber Line (DSL) and Fiber access 
architectures [TR-101]. It only impacts the first-hop router and it 
doesn’t need modifications on the other IPv6 nodes. This mechanism 
is fully effective if all the nodes of a point-to-multipoint domain 
(except the DAD proxy itself) perform DAD. 


This document explains also why the DAD mechanism [RFC4862] without a 
proxy cannot be used in a point-to-multipoint architecture with a 
"split—-horizon" forwarding scheme (IPv6 over PPP [RFC5072] is not 
affected). One of the main reasons is that, because of this 
forwarding scheme, IPv6 nodes on the same point-to-multipoint domain 
cannot have direct communication: any communication between them must 
go through the first-hop router of the same domain. 


It is assumed in this document that link-layer addresses on a point- 
to-multipoint domain are unique from the first-hop router’s point of 
view (e.g., in an untrusted Ethernet architecture, this assumption 
can be guaranteed thanks to mechanisms such as Media Access Control 
(MAC) address translation performed by an aggregation device between 
IPv6 nodes and the first-hop router). 


1.1. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


2. Background 


Terminology in this document follows that in "Neighbor Discovery for 
IP version 6 (IPv6)" [RFC4861] and "IPv6 Stateless Address 
Autoconfiguration" [RFC4862]. In addition, this section defines 
additional terms related to DSL and Fiber access architectures, which 
are an important case where the solution described in this document 
can be used: 


Customer Premises Equipment (CPE) 
The first IPv6 node in a customer’s network. 


Access Node (AN) 


The first aggregation point in the public access network. It 
is considered as an L2 bridge in this document. 
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Broadband Network Gateway (BNG) 
The first-hop router from the CPE’s point of view. 


VLAN N:1 architecture 
A point-to-multipoint architecture where many CPEs are 
connected to the same VLAN. The CPEs may be connected on the 
same or different Access Nodes. 


split-horizon model 
A forwarding scheme where CPEs cannot have direct layer 2 
communications between them (i.e., IP flows must be forwarded 
through the BNG via routing). 


The following figure shows where the different entities are, as 
defined above. 


4+------ + 4+----+ 
| CPE3 |--------- | AN | 
4+------ + ++ 
| 
| 
4+------ + 4+----+ 
| CPE2 |--------- | AN |---+ 
+ + ++ | 
+ | | 
| CPE1 |------------ + | 
+------ + 4+----- + 
| BNG |--- Internet 
+ + 


Figure 1: DSL and Fiber Access Architecture 
3. Why Existing IETF Solutions Are Not Sufficient 


In a DSL or Fiber access architecture depicted in Figure 1, CPEl, 
CPE2, CPE3, and the BNG are IPv6 nodes, while AN is an L2 bridge 
providing connectivity between the BNG and each CPE. The AN enforces 
a split-horizon model so that CPEs can only send and receive frames 
(e.g., Ethernet frames) to and from the BNG but not to each other. 
That said, the BNG is on the same link with all CPEs, but a given CPE 
is not on the same link with any other CPE. 


3.1. Duplicate Address Detection 
Duplicate Address Detection (DAD) [RFC4862] is performed when an IPv6 
node verifies the uniqueness of a tentative IPv6 address. This node 


sends a Neighbor Solicitation (NS) message with the IP destination 
set to the solicited-node multicast address of the tentative address. 
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This NS message is multicasted to other nodes on the same link. When 
the tentative address is already used on the link by another node, 
this last one replies with a Neighbor Advertisement (NA) message to 


inform the first node. So, when performing DAD, a node expects the 
NS messages to be received by any node currently using the tentative 
address. 


However, in a point-to-multipoint network with a split-horizon 
forwarding scheme implemented in the AN, the CPEs are prevented from 
talking to each other directly. All packets sent out from a CPE are 
forwarded by the AN only to the BNG but not to any other CPE. NS 
messages sent by a certain CPE will be received only by the BNG and 
will not reach other CPEs. So, other CPEs have no idea that a 
certain IPv6 address is used by another CPE. That means, ina 
network with split-horizon, DAD, as defined in [RFC4862], can’t work 
properly without additional help. 


3.2. Neighbor Discovery Proxy 


Neighbor Discovery (ND) Proxy [RFC4389] is designed for forwarding ND 
messages between different IP links where the subnet prefix is the 
same. An ND Proxy function on a bridge ensures that packets between 
nodes on different segments can be received by this function and have 
the correct link-layer address type on each segment. When the ND 
Proxy receives a multicast ND message, it forwards it to all other 
interfaces on a same link. 


In DSL or Fiber networks, when the AN, acting as an ND Proxy, 
receives an ND message from a CPE, it will forward it to the BNG but 
none of the other CPEs, as only the BNG is on the same link with the 
CPE. Hence, implementing ND Proxy on the AN would not help a CPE 
acknowledge link-local addresses used by other CPEs. 


As the BNG must not forward link-local scoped messages sent from a 
CPE to other CPEs, ND Proxy cannot be implemented in the BNG. 


3.3. 6LOWPAN Neighbor Discovery 


[RFC6775] defines an optional modification of DAD for IPv6 over Low- 
Power Wireless Personal Area Networks (6LOWPAN). When a 6LOWPAN node 
wants to configure an IPv6 address, it registers that address with 
one or more of its default routers using the Address Registration 


Option (ARO). If this address is already owned by another node, the 
router informs the 6LOWPAN node that this address cannot be 
configured. 


This mechanism requires modifications in all hosts in order to 
support the ARO. 
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3.4. IPv6 Mobility Manager 


According to [RFC6275], a home agent acts as a proxy for mobile nodes 
when they are away from the home network: the home agent defends a 
mobile node’s home address by replying to NS messages with NA 
messages. 


There is a problem for this mechanism if it is applied in a DSL or 
Fiber public access network. Operators of such networks require that 
an NA message is only received by the sender of the corresponding NS 
message, for security and scalability reasons. However, the home 
agent per [RFC6275] multicasts NA messages on the home link and all 
nodes on this link will receive these NA messages. This shortcoming 
prevents this mechanism from being deployed in DSL or Fiber access 
networks directly. 


4. Duplicate Address Detection Proxy (DAD-Proxy) Specifications 


First, it is important to note that, as this mechanism is strongly 
based on DAD [RFC4862], it is not completely reliable, and the goal 
of this document is not to fix DAD. 


4.1. DAD-Proxy Data Structure 


A BNG needs to store in a Binding Table information related to the 
IPv6 addresses generated by any CPE. This Binding Table can be 
distinct from the Neighbor Cache. This must be done per point-to- 
multipoint domain (e.g., per Ethernet VLAN). Each entry in this 
Binding Table MUST contain the following fields: 


o IPv6 Address 
o Link-layer Address 


For security or performances reasons, it must be possible to limit 
the number of IPv6 addresses per link-layer address (possibly, but 
not necessarily, to 1). 


On the reception of an unsolicited NA (e.g., when a CPE wishes to 
inform its neighbors of a new link-layer address) for an IPv6 address 
already recorded in the Binding Table, each entry associated to this 
IPv6 address MUST be updated consequently: the current link-layer 
address is replaced by the one included in the unsolicited NA 
message. 


For security or performances reasons, the Binding Table MUST be large 


enough for the deployment in which it is used: if the Binding Table 
is distinct from the Neighbor Cache, it MUST be at least the same 
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size as this last one. Implementations MUST either state the fixed 
size of the Binding Table that they support or make the size 
configurable. In the latter case, implementations MUST state the 
largest Binding Table size that they support. Additionally, 
implementations SHOULD allow an operator to inquire about the current 
occupancy level of the Binding Table to determine if it is about to 
become full. Implementations encountering a full Binding Table will 
likely handle it in a way similar to NS message loss. 


It is recommended to apply technical solutions to minimize the risk 
that the Binding Table becomes full. These solutions are out of the 
scope of this document. 


4.2. DAD-Proxy Mechanism 
When a CPE performs DAD, as specified in [RFC4862], it sends a 
Neighbor Solicitation (NS) message, with the unspecified address as 
the source address, in order to check if a tentative address is 
already in use on the link. The BNG receives this message and MUST 
perform actions specified in the following sections based on the 
information in the Binding Table. 

4.2.1. No Entry Exists for the Tentative Address 


When there is no entry for the tentative address, the BNG MUST create 
one with the following information: 


o IPv6 Address field set to the tentative address in the NS message. 


o Link-layer Address field set to the link-layer source address in 
the link-layer header of the NS message. 


The BNG MUST NOT reply to the CPE or forward the NS message. 
4.2.2. An Entry Already Exists for the Tentative Address 


When there is an entry for the tentative address, the BNG MUST check 
the following conditions: 


o The address in the Target Address field in the NS message is equal 
to the address in the IPv6 Address field in the entry. 


o The source address of the IPv6 Header in the NS message is equal 
to the unspecified address. 


When these conditions are met and the source address of the link- 


layer header in the NS message is equal to the address in the Link- 
layer Address field in the entry, that means the CPE is still 
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performing DAD for this address. The BNG MUST NOT reply to the CPE 
or forward the NS message. 


When these conditions are met and the source address of the link- 
layer header in the NS message is not equal to the address in the 
Link-layer Address field in the entry, that means possibly another 
CPE is performing DAD for an already owned address. The BNG then has 
to verify whether there is a real conflict by checking if the CPE 
whose IPv6 address is in the entry is still connected. In the 
following text, we will call IPv6-CPE1 the IPv6 address of the 
existing entry in the Binding Table, Link-layer-CPEl the link-layer 
address of that entry, and Link-layer-CPE2 the link-layer address of 
the CPE that is performing DAD, which is different from Link-layer- 
CPE1. 


The BNG MUST check if the potential address conflict is real. In 
particular: 


o If IPv6-CPE1 is in the Neighbor Cache and it is associated with 
Link-layer-CPEl, the reachability of IPv6-CPE1 MUST be confirmed 
as explained in Section 4.2.3. 


o If IPv6-CPE1 is in the Neighbor Cache, but in this cache it is 
associated with a link-layer address other than Link-layer-CPE1, 
that means that there is possibly a conflict with another CPE, but 
that CPE did not perform DAD. This situation is out of the scope 
of this document, since one assumption made above is that all the 
nodes of a point-to-multipoint domain (except the DAD proxy 
itself) perform DAD. 


o If IPv6-CPE1 is not in the Neighbor Cache, then the BNG MUST 
create a new entry based on the information of the entry in the 
Binding Table. This step is necessary in order to trigger the 
reachability check as explained in Section 4.2.3. The entry in 
the Neighbor Cache MUST be created based on the algorithm defined 
in Section 7.3.3 of [RFC4861], in particular by treating this case 
as though a packet other than a solicited Neighbor Advertisement 
were received from IPv6-CPE1. Thus, the new entry of the Neighbor 
Cache MUST contain the following information: 


* IPv6 address: IPv6-CPE1 
* Link-layer address: Link-layer-CPE1 
* State: STALE 


The reachability of IPv6é-CPE1 MUST be confirmed as soon as 
possible following the procedure explained in Section 4.2.3. 
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4.2.3. Confirmation of Reachability to Check the Validity of the 
Conflict 


Given that the IPv6-CPE1 is in an entry of the Neighbor Cache, the 
reachability of IPv6é-CPE1 is checked by using the Neighbor 
Unreachability Detection (NUD) mechanism described in Section 7.3.1 
of [RFC4861]. This mechanism MUST be triggered as though a packet 
had to be sent to IPv6-CPE1. Note that in some cases this mechanism 
does not do anything. For instance, if the state of the entry is 
REACHABLE and a positive confirmation was received recently that the 
forward path to the IPv6-CPE1 was functioning properly (see RFC 4861 
for more details), this mechanism does not do anything. 


Next, the behavior of the BNG depends on the result of the NUD 
process, as explained in the following sections. 


4.2.3.1. The Result of the NUD Process is Negative 


If the result of the NUD process is negative (i.e., if this process 
removes IPv6-CPE1 from the Neighbor Cache), that means that the 
potential conflict is not real. 


The conflicting entry in the Binding Table (Link-layer-CPEl) is 
deleted and it is replaced by a new entry with the same IPv6 address, 
but the link-layer address of the CPE is performing DAD (Link-layer- 
CPE2), as explained in Section 4.2.1. 


4.2.3.2. The Result of the NUD Process is Positive 


If the result of the NUD process is positive (i.e., if after this 
process the state of IPv6-CPE1 is REACHABLE), that means that the 
potential conflict is real. 


As shown in Figure 2, the BNG MUST reply to the CPE that is 
performing DAD (CPE2 in Figure 1) with an NA message that has the 
following format: 


Layer 2 Header Fields: 
Source Address 
The link-layer address of the interface on which the BNG 
received the NS message. 
Destination Address 


The source address in the Layer 2 Header of the NS 
message received by the BNG (i.e., Link-layer-CPE2). 
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IPv6 Header Fields: 


Source Address 
An address assigned to the interface from which the 
advertisement is sent. 


Destination Address 
The all-nodes multicast address. 


ICMPv6 Fields: 


Target Address 
The tentative address already used (i.e., IPv6-CPEl). 


Target Link-layer Address 
The link-layer address of the interface on which the BNG 
received the NS message. 


CPE1 CPE2 BNG 
| | | 
(a) | | | 
a 
| | | (c) 
| | | 
| (a) | | 
| | | 
| (e) | =========> 
| [Sareea a ea 48) 


CPE1 generates a tentative address 

CPE1 performs DAD for this one 

BNG updates its Binding Table 

CPE2 generates a same tentative address 
CPE2 performs DAD for this one 

BNG informs CPE2 that DAD fails 


ho @ Q © p 


Figure 2: DAD Failure 
The BNG and the CPE MUST support the unicast transmission on the link 


layer of IPv6 multicast messages [RFC6085], to be able, respectively, 
to generate and to process such a packet format. 
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5. 


6. 


Manageability Considerations 


The BNG SHOULD support a mechanism to log and emit alarms whenever a 
duplication of IPv6 addresses is detected by the DAD-Proxy function. 
Moreover, the BNG SHOULD implement a function to allow an operator to 
access logs and to see the current entries in the Binding Table. The 
management of access rights to get this information is out of the 
scope of this document. 


Security Considerations 


.1. Interoperability with SEND 


The mechanism described in this document will not interoperate with 
SEcure Neighbor Discovery (SEND) [RFC3971]. This is due to the BNG 
not owning the private key associated with the Cryptographically 
Generated Address (CGA) [RFC3972] needed to correctly sign the 
proxied ND messages [RFC5909]. 


Secure Proxy ND Support for SEND [RFC6496] has been specified to 
address this limitation, and it SHOULD be implemented and used on the 
BNG and the CPEs. 


2. Protection against IP Source Address Spoofing 


To ensure protection against IP source address spoofing in data 
packets, this proposal can be used in combination with Source Address 
Validation Improvement (SAVI) mechanisms [RFC6620] [SAVI-SEND] 
[SAVI-MIX]. 


If SAVI mechanisms are used, the SAVI device is the BNG, and the 
Binding Anchor for a CPE is its MAC address, which is assumed to be 
unique in this document (cf. Section 1). 
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Appendix A. DAD-Proxy State Machine 


This appendix, which is informative, contains a summary (cf. Table 1) 
of the actions done by the BNG when it receives a DAD-based NS 
(DAD-NS) message. The tentative address in this message is IPv6-CPE1 
and the associated link-layer address is Link-layer-CPE2. The 
actions are precisely specified in Section 4.2. 


=-=- + 
New event | 


* No entry for 
IPv6-CPE1 in the 
Binding Table. 


Create an entry 
for IPv6-CPE1 
bound to Link- 
layer-CPE2 in the 
Binding Table. 


message 
reception. 


* Entry for 
IPv6-CPEL in the 
Binding Table. 


Existing 
entry. 


Existing 
entry. 


+ + 
| | 
+ + 
| | 
| | 
| | 
| | 
| | 
| | 
| * Link-layer-CPE2 | 
bound to IPv6-CPE1 
| in the Binding | 
| Table. | 
| * Another link- | Conflict? 
| layer address, | 
| Link-layer-CPE1, | 
bound to IPv6-CPE1 
| in the Binding | 
| Table. | 
Conflict? | * IPv6-CPE1 | 
| associated to | 
| Link-layer-CPE1 in | 

the Neighbor 
| Cache. | 
| * IPv6-CPE1 | 
| associated to | 
| another link-layer | 

address than Link- 
| layer-CPEl in the | 
| Neighbor Cache. | 
| * IPv6-CPEl is not | 
| in the Neighbor | 
| Cache. | 
| | 


Reachable? 


Out of scope. 


Create an entry Reachable? 
for IPv6—-CPE1 
associated to 
Link-layer-CPE1 in 
the Neighbor 
Cache. 
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| Reachable? | * NUD process is | IPv6-CPE2 is bound | - | 
| | negative. | to Link-layer- | 

CPE2, instead to 

Link-layer-CPE1, 
| | | in the Binding | | 
| | | Table. | | 
| | * NUD process is | A NA message is |- 
| | positive. | sent. | 
À Re —— Re —— +------------ + 


Table 1: DAD-Proxy State Machine 
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